Continue port scan from the requested range

When the first candidate port is unavailable, this branch recurses with port + 1, but port here is the .then(...) argument and is null on failure, so the next scan starts at 1 instead of startPort + 1. In parallel E2E runs this can probe privileged/irrelevant ports and introduce long retry delays or launch failures before reaching a usable port.

Useful? React with 👍 / 👎.

Pass CDP port via Electron CLI switch

Setting REMOTE_DEBUGGING_PORT in the environment does not configure Electron's remote debugging endpoint; Electron expects the --remote-debugging-port=<port> launch argument. Because the switch is never added to the spawned command, the app may start without an exposed CDP port, causing E2E clients to fail when attaching to the expected debugger endpoint.

Useful? React with 👍 / 👎.

Resolve timed-out port probes before flipping completion

In findAvailablePort, the timeout handler calls cleanup() before deciding whether to resolve(null). Because cleanup() sets completed = true, the subsequent if (!completed) branch is always false, so a probe that times out never resolves and later listen callbacks are also ignored (completed is already true). Under slow/loaded CI where the listen callback is delayed past 100ms, launchApp() can hang indefinitely while searching for a port.

Useful? React with 👍 / 👎.

Use liveness check instead of proc.killed for force-kill

The force-kill fallback is gated by if (!proc.killed), but proc.killed becomes true immediately after sending the initial SIGTERM and does not mean the process has exited. This means the SIGKILL path is effectively disabled for stubborn Electron processes, so close() may resolve while the app is still running and leak processes across E2E runs.

Useful? React with 👍 / 👎.

Treat non-zero early exits as launch failures

launchApp only records spawn-level failures via the 'error' event, but a child that starts and then exits with a non-zero code during startup is merely logged and still returned as a “launched” app. In that scenario, E2E runs proceed with a dead process and fail later when attaching to CDP, making failures flaky and harder to diagnose; this exit path should set a launch failure signal (or re-check proc.exitCode after the startup wait) and reject immediately.

Useful? React with 👍 / 👎.

Short-circuit close when child has already exited

The early-return guard uses proc.killed, which remains false when a process exits on its own. If Electron crashes/exits before close() is called, this path still sets up a new exit listener (after the event already fired) and then waits for the 5s force-kill timer before resolving, adding unnecessary teardown delays and slowing failing test runs.

Useful? React with 👍 / 👎.

Use signalCode in exited-process guard

Fresh evidence in this revision: the close() early-return guard now checks proc.signalDescription, but Node ChildProcess exposes signalCode instead, so processes that already exited via signal still fall through to the teardown path. In that case the new exit listener never fires (event already emitted), and close() waits the full 5-second force-kill timeout on every affected test, slowing and adding flakiness to failing E2E runs.

Useful? React with 👍 / 👎.

Isolate test instances with separate user data dirs

This launcher always sets TEST_MODE=true to bypass the single-instance lock, but it does not provide a per-instance userData override, so parallel E2E runs will share the same on-disk profile and databases. Because the main process still reads/writes default app.getPath('userData') storage paths, concurrent test processes can interfere with each other (state leakage, lock contention, flaky assertions) and may mutate a developer’s real local profile when running tests outside CI.

Useful? React with 👍 / 👎.

Treat signal-terminated startup exits as launch failures

The startup exit handler only records the numeric code, but Node reports signal-based termination as code === null with a non-null signal. In that case the post-wait check (exitCode !== null && exitCode !== 0) is bypassed and launchApp() can return success even though Electron has already died, causing downstream CDP attach failures that are harder to diagnose.

Useful? React with 👍 / 👎.

Skip legacy data migration in E2E userData mode

Setting app.setPath('userData', e2eUserDataDir) here reroutes all startup data operations to the test directory, but init() still runs migrateDataIfNeeded(). In this repository, migrateFromLegacyDir() removes Documents/ChatLab after copying, so running E2E locally on a machine that still has legacy data can migrate/delete real user data into a disposable E2E path. Please gate legacy migration off in TEST_MODE (or when CHATLAB_E2E_USER_DATA_DIR is set) to avoid destructive side effects outside CI.

Useful? React with 👍 / 👎.

Reserve the CDP port instead of releasing before spawn

This returns the candidate port only after closing the probe socket, so the port is no longer reserved during the gap before Electron binds --remote-debugging-port. In parallel E2E starts, two workers can both observe the same port as free and then race to claim it, causing intermittent launch/attach failures. The launcher should avoid this TOCTTOU window (for example by deterministic per-worker ports or by holding a reservation until process startup).

Useful? React with 👍 / 👎.